Unless otherwise indicated herein, the materials described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In many instances, it can be useful to remotely monitor printing devices. By monitoring these devices, it can be determined whether replacement paper or toner needs to be supplied, for example. Additionally, when a multiplicity of printing devices are available for performing a given printing task, data gathered by monitoring, such as a number of pending jobs or a number of paper jams experienced within the last day, can be used in the process of choosing which of the printing devices to use.
Conventionally, monitoring printing devices is done using Simple Network Management Protocol (SNMP), in which the printing device acts as a managed device, constantly executing an “agent” (a software that communicates monitored printer parameters to a managing device). In many configurations, the printing device will only respond with parameter values if polled by the managing device (such metadata is defined within a management information base, or MIB).
Frequently, the managing device only performs actions based on the parameter values if they reach a critical point, such as when the amount of toner falls below 10%, for instance. Thus, superfluous polling by the managing device can occur. In some cases, however, the “agent” transmits a “trap”, which is an asynchronous notification to the managing device. This enables the “agent” to notify the managing device of important events using an unsolicited message.
Optimally, printing devices could be configured to transmit a “trap” every time a threshold condition were met, such that at such a threshold, at least one terminal device within the network of the printing device would benefit from learning of such a threshold condition being met. Some printing devices, however, have limited, on-board resources. Due to this, such printing devices may only be able to store a limited number of threshold conditions.
Furthermore, printing devices can be monitored by having the printing devices communicating with a cloud server over the public Internet using protocols such as Extensible Messaging and Presence Protocol (XMPP), Hypertext Transfer Protocol (HTTP), Bidirectional-streams Over Synchronous HTTP (BOSH), WebSocket, Representational State Transfer (REST), or Simple Object Access Protocol (SOAP), for example. In such methods, polling by a managing device (cloud server) does not occur, and traffic efficiency depends primarily on how accurately the printing devices know which data to submit to the cloud server, and when.
Therefore, such methods still require configuring many triggers within the printing devices. Again, some printing devices are limited by their embedded resources. Consequently, only a limited number of threshold conditions can be stored even using these methods.